1. Field of the Invention
The present invention relates generally to the field of telecommunications, and more particularly to an automated system for detecting and preventing fraudulent telephone calls in a telecommunications network.
2. Description of the Related Art
Fraudulent telephone activity for domestic and international calls presents a significant and increasing problem to carriers of telecommunications networks, such as the assignee of the present invention, AT&T Corporation. Such fraudulent activity may include calling card fraud and/or subscriber fraud.
Calling card fraud involves the misappropriation of a valid calling card number and then using the misappropriated number to place toll calls which are billed to an unsuspecting subscriber.
Subscriber fraud involves fraudulent usage by an otherwise legitimate subscriber. Typically, this type of fraudulent activity occurs when a subscriber signs up for telecommunications services and proceeds to use the services with no intent to ever pay for the services provided. Such a fraudulent/delinquent subscriber would continue to use the services without paying until the network access was blocked by the service provider. Subscriber fraud may also occur through the subscriber's illegal call forwarding, illegal third party number billing schemes, illegal collect schemes, etc.
Conventional telecommunications systems today, such as what is known as the public switched telephone network (PSTN), comprise several interdependent networks: the local or exchange area network, which is typically operated by a local telephone company or local exchange company (LEC); and the toll network, which is operated by a long distance or interexchange carrier (IXC) such as AT&T Corporation.
In the conventional PSTN, a given telephone within a LEC network is capable of accessing the IXC network through known gateway switching equipment, such as AT&T's 4ESS.TM. and 5ESS.TM. toll switches and operator services position system (OSPS.TM.) switch. Upon access to the IXC network, a toll call may be completed outside the LEC network. However, because the LEC's typically perform credit and collection processes on the IXC's behalf under contracts between the IXC and the LEC's, it has become increasingly difficult for the IXC to detect and prevent fraudulent telephone calls within the IXC network.
Prior attempts to detect and prevent such fraudulent telephone calls have been made, but with generally unsatisfactory results. For instance, because the LEC's are responsible for billing most customers utilizing the IXC's toll services, the LEC would provide customers who were delinquent in paying their bills with a predetermined grace period prior to suspending the delinquent customer's access to the IXC network for domestic and international long distance service. As a result, the IXC would continue to incur high revenue losses as a result of the delinquent customer's continued use of long distance services during this grace period until access to such service was suspended by the LEC.
To combat this type of subscriber fraud, the IXC has previously attempted to block switch-accessed toll calls (international or domestic) at the originating/access 4ESS.TM. switch (e.g., 1+/011+calls) by creating one or more Network Call Denial (NCD) databases containing billing numbers for customers known to be delinquent in payment to the IXC. Such billing numbers include the number from which the call is placed (ANI), the number to whom the call is directed for collect calls, the third party number when the call is billed to that third party, and calling card numbers issued by the IXC.
As illustrated in FIG. 1, when specified call types (i.e., 1+calls) are introduced into the IXC network, the 4ESS.TM. switch 10! launches a query to a NCD database 12! (in parallel with the call processing) through a common channel signalling network (CCS7 network), such as AT&T's 2STP.TM. network. The NCD database 12! is then searched to determine if the billing number matches that of a delinquent customer stored in the database 12!. When a match is found, a response is transmitted back to the 4ESS.TM. switch 10! to identify and terminate the call. Thus, the IXC was able to block calls within its network for customers who are delinquent in payment when the billing number matches that of a previously known delinquent customer stored in the NCD database 10!.
However, the above-described NCD database 10! proved ineffective in detecting and preventing fraudulent credit card calls for credit cards issued by the LEC (LEC cards). In an attempt to prevent such fraudulent credit card calls, the IXC must access the line information database (LIDB) of the LEC in order to validate the credit card before the call is completed in the IXC network, as illustrated in FIG. 2.
In operation, when a LEC credit card call is placed by a customer, the call is processed in the IXC network 1! by an OSPS.TM. switch 20! which receives the LEC card number as the billing vehicle. The OSPS.TM. switch 20! thereafter launches an appropriate query Query 1! through the CCS7 network 24! (such as AT&T's 2STP.TM. network) to a line service application/network control point (LSA/NCP) 22! within the IXC network 1!. Upon receipt of the query Query 1!, the LSA/NCP 22! checks a "hot list" (a.k.a. deactivation list) stored in the LSA/NCP 22! for that particular LEC card number and associated personal identification number (PIN). If the LEC card number and associated PIN match a card number and PIN contained in the "hot list", the LSA/NCP 22! sends a deny response through the CCS7 network 24! back to the OSPS.TM. switch 20!, which in turn prevents completion of the call.
If the LEC card number and associated PIN do not match any numbers and PIN's stored in the LSA/NCP "hot list", then the LSA/NCP 22! was required to send a subsequent query Query 2! through the CCS7 network 24! to the LIDB 26! in the LEC network 2! for "true" validation by the LEC. The LIDB 26! in the LEC network 2! contains a list of valid credit card numbers and PIN's issued by that particular LEC, as well as a list of LEC credit card numbers that should be denied due to unauthorized/fraudulent usage and/or delinquent payment.
Should the LEC card number and associated PIN transmitted in the second query Query 2! fail to match one of the valid numbers stored in the LIDB 26! of the LEC network 2! (invalid LEC card number and/or PIN), then the LIDB 26! returns a first response Response 1! to the LSA/NCP 22! to deny the call and the LSA/NCP passes the "deny" response Response 2! to the OSPS.TM. switch 20! to prevent completion of the call.
In contrast, however, should the LEC card number and associated PIN transmitted in the second query Query 2! match one of the valid numbers stored in the LIDB 26!, then the LIDB 26! returns a response Response 1! to the LSA/NCP 22! to allow the call and the LSA/NCP 22! passes the "allow" response (Response 2) to the OSPS.TM. switch 20! to allow the call. The LSA/NCP 22! also stores the LEC card number and PIN in a fraud tracking list, and increments the card usage by one each time a call is made that is to be charged to that particular LEC card number. If the usage count for a particular LEC card number and PIN exceeds a predetermined threshold in a given time period (velocity), then the LSA/NCP 22! will identity that particular LEC card number and PIN combination as potentially fraudulent.
While the above-described LSA/NCP application has met with moderate success in preventing fraudulent calls billed to LEC cards by validating the cards and monitoring the frequency of calls in a given period of time (velocity), such application has several drawbacks. First, to validate the LEC card, the IXC must communicate outside the IXC network with the LIDB 26!. In addition, unscrupulous callers seeking to perpetrate fraudulent calls are becoming more and more sophisticated. As such, these fraudulent callers have learned to recognize the velocity threshold levels set by the IXC and continue to go undetected by maintaining their fraudulent calls below the velocity threshold levels. In this manner, these fraudulent callers adjust their fraudulent calling patterns to go undetected by placing smaller numbers of fraudulent calls (below the velocity threshold) and instead hold each fraudulent call for longer (and more expensive) durations.
To prevent fraudulent calls charged to credit cards issued by the IXC (IXC cards), the IXC has also previously utilized a customer account services/network control point (CAS/NCP) 30! in the IXC network 2! which contains information concerning the IXC cardholder. Referring to FIG. 3, when an IXC credit card call is received from the LEC network 2! by an OSPS.TM. switch 20!, the OSPS.TM. switch 20! sends a query Query 1! to the CAS/NCP 30! through the CCS7 network 24! to validate the call. Like the LIDB 26! described above and illustrated in FIG. 2, the CAS/NCP 30! checks the IXC card number and PIN to ascertain its validity by comparing the IXC card number and PIN to those stored in a database within the CAS/NCP 30!. If the card number and PIN match and the account is in good standing, the CAS/NCP 30! sends a response Response 1! back to the OSPS.TM. switch 20! to allow the call.
In addition, like the LIDB 26!, the CAS/NCP 30! may increment the card usage by one each time a call is made that is to be charged to that particular IXC card number and store the usage count in its database. If the usage count for a particular IXC card number exceeds a predetermined threshold in a given time period (velocity)--which threshold is also stored in the database of the CAS/NCP 30!--then the CAS/NCP 30! will identify that particular IXC card number as potentially fraudulent.
Alternatively, if the card number and/or PIN do not match those stored in the CAS/NCP database, the account is overdue, or the velocity threshold is exceeded, then the CAS/NCP 30! may take appropriate action, such as terminating the call attempt or allowing the call but notifying the appropriate work center of the IXC for customer follow-up.
Additionally, credit limits could be placed on particular IXC card numbers stored in the database of the CAS/NCP 30!. When the initial query Query 1! is transmitted to the CAS/NCP 30! by the OSPS.TM. switch 20!, the CAS/NCP 30! can also verify that the credit amount for the particular IXC card is not exceeded. If the credit amount is not exceeded, the CAS/NCP 30! may instruct the OSPS.TM. switch 20! in its response Response 1! to allow the call. Periodically, an adjunct in communication to the OSPS.TM. switch 20! may determine the actual cost of the IXC card call to that point in time and may transmit that information to the CAS/NCP 30! through the CCS7 network 24! whereupon the CAS/NCP 30! will deduct that amount from the IXC card's credit and store the new amount in the database. When the credit amount is exhausted, the CAS/NCP 30! may instruct the OSPS.TM. switch 20! via the CCS7 network 24! to terminate the call in progress or to take some further action, such as having an operator access the call to request another form of payment.
While the CAS/NCP 30! has been successfully used by the IXC, its use is limited to IXC card calls. Accordingly, the CAS/NCP 30! is not capable of detecting potentially fraudulent calls utilizing billing methods other than an IXC issued credit card.